Working with Gigabyte-Sized Images

When you load an image into ImageGear image handle, or create one, its pixel data is stored in the computer’s random access memory (RAM) by default. As the physical memory usage grows, the system swaps less used blocks of memory from running applications to the system Page file. If an application tries to allocate a block of memory comparable with the computer’s RAM size, the system has to push its own resources to the Page file. This makes the system extremely unresponsive. If an application requests more memory than (size of the RAM + the page file size – amount of memory used by the system), such request cannot be fulfilled, and the allocation fails.

ImageGear allows working with such large images by allocating memory for the DIB via a memory mapped file. On a 64-bit operating system, this allows allocating images nearly as large as the amount of free disk space on the computer, without overloading the RAM and affecting the system responsiveness. On a 32-bit OS, maximum total size of DIBs allocated simultaneously in several processes cannot exceed 3…3.5 Gb, and the size of all DIBs allocated in one process cannot be greater than 2 Gb; however, using memory mapped files still makes working with large images much more convenient.

If the images are not big, or there is plenty of free RAM, keeping image pixels in the RAM provides better performance than using the memory mapped files. However, when image size is comparable to RAM size, or is greater, memory mapped file usage provides much better performance than storing the image in memory.

ImageGear does not use memory mapped files for 1-bit images. However, ImageGear uses Run Ends compression for storing them, so they rarely occupy large amounts of memory.

This section provides the following information: